“我，计算机毕业 33 年，不写代码也能在软件行业谋生”
【CSDN 编者按】自1989年以来，一直在软件领域从业的 Jim Grey 积攒了33年的宝贵经验，也见证了软件行业的变迁与发展。看看过去的软件工程师都是怎么工作的，或许就能知道今天的工作是何等幸福了。
原文链接：https://dev.jimgrey.net/2022/07/05/working-in-the-software-industry-circa-1989/
声明：本文为 CSDN 翻译，转载请注明来源。
以下为原文：
自1989年以来，我一直在软件行业谋生。很久以前我写过代码，但我的职业生涯主要建立在测试、技术写作和管理发布、项目和人员上。
今天，请允许我讲一个很长的故事。
我在软件行业工作的第33个周年纪念日是刚刚过去的星期天，即7月3日。我会记得这个日期，因为我工作的第二天是一个带薪假期。我想告诉你，我们的行业已经走过了多远，以及我们已经学到了多少东西。
这是我工作的第一家软件公司ACD的公司标志，由于该公司在1996年就已消失，下面这张低分辨率的Logo标志是我能在网上能找到的所有东西。
我工作的第一家软件公司是位于印第安纳州特雷霍特的应用计算设备公司，和那些聪明的同事们一起工作是件快乐的事。我们制造管理电话网络的软件，我们的客户有AT&T、US Sprint（现在只叫Sprint）、GTE（现在的Verizon），以及几个地区性贝尔运营公司（即固定电话公司），包括Ameritech（为印第安纳州服务）、BellSouth和Pacific Bell。这些公司主要提供固定电话（商业中的“有线”）服务，但有些公司也开始涉足移动服务。这是很复杂的管理，我们的软件产品也相应地很复杂。
我不是一个软件工程师，而是一个技术作家。我写了大量的纸质手册，发给客户，向他们解释如何安装、配置和使用我们的软件。当时的软件行业非常小，当我获得数学/计算机科学学位毕业证书时，经济正处于衰退期。我没有得到很多编程工作的面试机会，哪怕面试了也没有被录用。
那个夏天我住在校园里寻找工作。但夏天很快就会结束，那时我就必须回家和爸爸一起生活。而我丝毫不想这样，所以我决定转而在一家软件公司找其他工作，包括质量保证、支持、IT、保安等任何工作。
我学校的一位教授认识ACD公司的人，并向他们推荐了我。这家公司需要一个技术作家。我说我很乐意做这份工作，于是他们以每年23,000美元（今天约为54,000美元）的价格雇用了我。令我惊讶的是，我发现我喜欢写作，甚至比写代码的兴趣要更为浓厚，我变得非常擅长向用户解释那些技术含量高的软件。
过去的软件行业是如何工作的
我真正想告诉你的是，我除了对超级聪明的同事们感到敬重之外，在那里工作是什么样子的。
那时的软件行业与现在非常不同，很多现在认为理所当然的东西在当时都不存在。尽管已经有了互联网，但却没有网络。软件是通过磁带或软盘交付给客户的，CD刻录机仍是几年后的事。Java、JavaScript、.NET也都不存在。当时普遍使用的语言是C/C++、FORTRAN、Pascal、Ada、Perl、Tcl和Lisp，当然还有COBOL。我在大学里有一份暑期工作是做Pascal程序员。尽管面向对象的编程是存在的，但是却还是小众。当时主要的面向对象语言是Smalltalk。我的一个大学室友在Smalltalk社区非常有名，甚至还写了一些关于Smalltalk的书。
支持团队负重前行
那会儿还没有出现软件订阅的情况。彼时只要有公司预先支付软件的全部费用，就可以永远使用他们购买的软件版本，不过，后续他们需要为软件的重大升级再次付费。一些聪明的公司将他们的付款分期在几年内，但许可证仍然是永久性的。
当你把产品的新版本邮寄给客户时，他们中的大多数人不会马上安装它，有些人则永远不会安装它。
通常他们会说，“我们现在使用的版本对我们来说很好。”
这句话是我们在软件支持方面的一个噩梦。经过迭代，我们公司最终决定只支持软件最新的四个版本，这一决定让我们的客户感到非常沮丧，但做 IT支持的团队却对此不胜感激。
可怕的长周期项目
当时最好的SDLC（系统生命周期）是瀑布式，这种模式所包含的所有问题都没有被我们忽视。整个行业都在做长周期的项目，比如用两个月来做需求收集和设计规范，接着再耗费九个月进行编码，继而是为期三个月的测试。现在回过头想想，即使我们当时看到小规模、频繁发布的项目能在很多方面都能得到好处（但大多没有看到），我们也无法真正做到这一点。因为，在交付的成本很昂贵，而且对我们的客户来说，频繁的安装也会造成干扰。
我们认为，软件开发项目应该像制造或建筑项目一样进行管理。于是我们建立了巨大的甘特图，我们把它贴在一面巨大的墙上，用它来跟踪计划和完成的工作。在编码的第一周，我们会发现一些我们在设计阶段没有想到的事情，我们不得不重新规划整个项目，并重新打印新的甘特图。那时的我们从未幸免于这种状况，并在每个项目中都是如此。
测试人员的噩梦
当代码最终到达QA时，测试人员会为成百上千的 Bug 焦头烂额。在软件到达测试人员手中之前，他们几乎没有见过这个软件，而且在设计、研发阶段也只是勉强参与。由于Bug太多，测试阶段总是需要比计划的时间长。但那时我们已经向客户承诺了一个交付日期，为了达到承诺的日期，每个版本都会有一大堆已知的错误，我们会在几周后所谓的“快速跟踪”版本中修复，而聪明的客户学会了在“快速跟踪”版本出现之前不安装之前的版本。
由于这一切，项目总是变成可怕的“死亡长征”，在发布日期前的几周里，有很多深夜和周末都得加班。尽管职业倦怠感很强，但很少有人因此而辞职，因为我们认为这是必须要做的。反正也没有多少其他的软件公司可以投靠，况且其他公司也有“死亡长征”。
糟糕的工作环境
ACD公司的技术栈（当时我们还没有这个词）是基于两种UNIX的C++，即：数字设备公司的Ultrix和IBM的AIX。我们的软件在DEC和IBM基于RISC的微型计算机上运行，这些机器的大小与酒吧冰箱差不多。我们身处一个又大又冷又有一大堆机器的机房里，开源工作。因为工作地点所在的是特雷霍特的郊区，我们的电力是由一个农村电力合作社提供的，不是很可靠，这也导致几乎每个月都要停一次电。微型计算机是按顺序连接的，必须按顺序启动，一台机器要花10分钟才能启动，所有的计算机要花三个多小时才能完成启动。如果下午2点以后电源闪烁，我们都会回家休息一天。
但没有人能在家里工作，因为微型计算机只能在办公室内的网络上使用。我认为从技术上讲，将它们连接到互联网上并非不可能，但在家里，我们都只有靠拨号接入。这导致不仅速度是个问题，而且家人也不喜欢电话被你的工作一占用就是几个小时。
落后的技术及设备
每人的桌上都有一个终端用于工作。起初，所有的工程师都使用古老的VT100终端，但后来公司给他们花2000美元买了巨大的图形终端，这样他们就可以在X Windows中建立用户界面。当时用户体验设计还未成形、前端和后端工程之间的区别也没有。我们的软件工程师设计了我们的用户界面，但他们中的大多数人都不擅长这个。
作为一个技术作家，我的桌子上有一台运行System 6的Macintosh II电脑。(System是MacOS过去的名字)它有8MB的内存，这在当时是一台好到令人尖叫的机器。我用一个叫Interleaf的程序编写手册，在Mac上使用终端模拟器来连接微型计算机。
当时有一场关于文本编辑器的“神圣战争”。彼时IDE还没有出现，所以我们都用文本编辑器编码。我坚定地站在Emacs阵营，但我的大多数同事都喜欢Vi。
我们的终端是在一个连接到微型计算机的令牌环网络上的。令牌环网络只在其上的节点链是完整时才发挥作用，因为信息在网络上流经每个节点。在我决定重新安排我的小隔间的那天，我并不知道这一点。当我拔掉我的终端来移动它时，我把一半的网络都弄坏了。那一天，我被所有人“嫌弃”了。
AIX和Ultrix以及它们的底层硬件有很大的不同，我们的代码是由IF AIX和IF ULTRIX语句组成的一团糟。有时我们不得不为整个子程序和函数编写独立的AIX和Ultrix版本。我们不得不编译两次代码，一次是在AIX上，一次是在Ultrix上。1995年Java问世时，它完全改变了游戏规则。你是说我们可以写一个代码库，没有依赖操作系统或硬件的IF，也没有单独的例程，并在任何可以运行JVM的机器上运行？这简直是巫术！
单一的团队文化
那时的软件行业的文化远没有现在这么多元化。ACD的每一个软件工程师都是白人，他们中的大多数都在35岁以下。没有有色人种，也没有移民。那时在外面任何地方工作都不安全。我知道我团队中的一个技术作家是同性恋，但这只是因为我们已经成为朋友，他决定冒着风险向我坦白。
苛刻的层级要求
该软件工程团队有两个头衔。软件工程师和高级软件工程师。这在当时的行业中是很典型的。你必须有至少10年甚至是15年的软件工程经验，才能被考虑晋升为高级软件工程师。那时，高级的标准也比较高。那时的高级工程师的技术和经验更像今天的首席工程师。
总之，我在ACD非常开心，也喜欢在那里工作。然而，由于那会儿只有这么多的电话公司，因此我们可能有十几个客户。我们与US Sprint的关系一直不稳定，有一天我们把他们惹毛了，他们取消了合同，还让我们为此起诉他们。这笔收入的损失使我们陷入困境，也是ACD走向衰败的开始。我不想在特雷霍特失业，所以我在印第安纳波利斯找了一份工作并搬了家。当时和现在一样，印第安纳州的大部分软件开发都集中在印第安纳波利斯。
斗智斗勇的工作
让我告诉你关于ACD的最后一个故事，它涉及US Sprint公司。US Sprint公司对我们的软件发布了太多的错误而感到愤怒。他们给我们发了一份清单，列出了他们希望修复的所有错误，他们希望在星期一之前修复这些错误，否则他们就会购买竞争对手的产品，并放弃我们。工程团队没日没夜地工作，试图修复这些错误。他们一直工作到周末，但到周日早上，他们仍然没有解决几个特别棘手的错误。
当时我们必须用磁带盒运送代码。联邦快递的最后期限又在周日，而工程师们仍然没有完成。有人眼前一亮，想出了一个绝妙的主意：我们会给US Sprint公司寄去一盘空白的磁带，并附上我们一贯的信件，列出了发行中的变化。
星期一，我们接到了US Sprint公司的电话，对方表示，无论他们如何尝试，他们都无法从我们寄给他们的磁带中加载软件。这时，我们的支持部门已经准备好了。"哦！我们非常抱歉，一定是什么地方出了问题！我们今天会给你发送另一盘磁带。"
那时，工程师们已经修复了最后两个错误。我们把真正的维护版本写到了新的磁带上，并把它送到了US Sprint公司。于是ACD这家公司又活了下来，并继续战斗。